-
Notifications
You must be signed in to change notification settings - Fork 46
Feat cache for the queue #496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
🦋 Changeset detectedLatest commit: 56dca94 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
366d593
to
e3f9be7
Compare
fc3c46d
to
a3d5d7e
Compare
a3d5d7e
to
48eb27f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's merge this for 1.1.
Could you please work on a doc PR when you have time to describe the Queue Cache and the options so that we can merge at the same time.
48eb27f
to
9842527
Compare
Doc in opennextjs/docs#156 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Let's add this to the next minor
Co-authored-by: Victor Berchet <[email protected]>
Durable object queue should already be able to handle most situation, but there is a case where for a single route, while being stale, you reach the limits of what a single durable object is capable of handling.
For this kind of cases, adding cache in front will help (but in case of error between the worker and the durable object, revalidation may take more time to happen)
There is 1 other upgrade that we could do for this case: